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ABSTRACT 

The European Retrieval Carrier (EURECA) was 
launched on its first flight on the 31st July 1992 by 
the Space Shuttle Atlantis. EURECA is 
characterised by several new on-board features, 
most notable Packet Telemetry and a partial 
implementation of Packet Telecommanding using 
an early version of the Command Operation 
Procedure (COP-1) protocol. EURECA has also 
very low contact time with its Ground Station, with 
a consequent high number of out-of-visibility on- 
board operations. This paper concentrates on the 
implementation and operational experience with the 
COP-1 Protocol and the effect the short ground 
contact time has on the design of the Commanding 
System. Another interesting feature is that the 
COP-1 is implemented at the Control Centre rather 
than at the Ground Station. The COP-1 protocol 
also successfully supported the mission during the 
Launch where commands were sent via NASCOM 
and the Shuttle. 

Key Words: Packet Telecommanding, COP-1 
protocol. Command Verification. 

L INTRODUCTION 

The European Retrievable Carrier (EURECA) is a 
reusable platform supplying power, cooling, ground 
communications and data processing services to a 
variety of independently-operated payloads (ref 1). 
Fifteen experimental facilities are carried to support 
more than fifty individual experiments, most 
relying on the microgravitational environment. Die 
operational altitude is 500 Km. Die Operations 
Control Centre (OCC) is at ESA’s European Space 
Operations Centre (ESOC) in Darmstadt, 
Germany. The primary groundstaiions are at 
Maspalomas in the Canary Islands and Kourou at 
French Guinea. During the deployment and 
retrieval phases contact is maintained via the 
NASA Communications Network and the STS. 


At ESOC, operational data processing is carried 
out on the Eureca Dedicated Computer System 
(EDCS) that hosts the mission-configured 
Spacecraft Control and Operations System (SCOS) 
(ref 2) and the Eureca-Specific Software (ESS) 
applications. 

The Eureca-Al mission has characteristics differing 
quite considerably from those of missions hitherto 
supported at ESOC. One of these is the use of 
Packet Telemetry and Packet Commanding. Eureca 
is the first ESA application of Packet Telemetry 
and Commanding. 

2. PACKET TELEMETRY AND 

COMMANDING 

2.1 TELEMETRY 

Eureca’s telemetry is packetised according to 
standards based on a Recommendation of the 
Consultative Committee for Space Data Systems 
(CCSDS), ref. 3. 

The Packet telemetry recommendation (ref. 3) uses 
two principal data structures, the source packet and 
the Transfer Frame, source packets being 
multiplexed within transfer frames. Each on-board 
source must label its data packets using CCSDS 
defined headers. Die transfer frames are of fixed 
length, optimised for high-performance transfer to 
the ground. For Telecommand verification each 
Transfer Frame has attached a Command Link 
Control Word (CLCW) that is used by the COP-1 
Protocol. The CLCW is essentially meant to be 
used in automated transmission/retransmission 
processes. Therefore, CLCW data must be 
delivered error free to the sending end of the 
Telecommanding system. The protocol information 
contained in the CLCW is such that it is not 
required that the Telemetry Transfer Frame rate 
match the Telecommand Block Rate. However, 
some minimum CLCW sampling rate must be 
established for the proper operation of the COP-1 
protocol. 
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2.2 TELECOMMAND 


C0P4 Protocol 


Unlike the telemetry system, the Eureca 
ielecommanding system has to support the old 
command standards (Ref. 4) and the new Packet 
command standard (Ref. 5). The reason for this is 
the way it has been implemented on board. 
Command decoders using the old standard have 
been used as a basis, but the extra services of the 
packet commanding have been built into the 
On-Board Computer (OBC). Thus when the OBC 
is nominally activated, the commanding system acts 
like a packet command system, using a subset of 
COP-1 of the standard (ref. 5). If the OBC is off, 
the old standard has to be used. 

3. COP-1 PROTOCOL 

NOTE: In this section, although the word COP-1 
is used, EURECA has only implemented a subset 
of the COP-1. Hie EURECA terminology mid 
services are not completely compatible with the 
latest issue of the CCSDS recommendation. 

COP-1 is a closed-loop Telecommand Protocol that 
utilises sequential ("go-back-n”) retransmission 
techniques to correct Telecommand Blocks that 
were rejected by the spacecraft because of error. 
COP-1 allows Telecommand Blocks to be accepted 
by the spacecraft only if they are received in strict 
sequential order. This is controlled by the 
necessary presence of a standard return data report 
in the telemetry downlink, the Command Link 
Control Word (CLCW). A timer is used to cause 
retransmission of a Telecommand Block if die 
expected response is not received, with a limit on 
the number of automatic retransmissions allowed 
before the higher layer is notified that there are 
problems in sending Telecommand Blocks. The 
retransmission mechanism ensures that: 

No Telecommand Block is lost 

No Telecommand Block is duplicated 

No Telecommand Block is delivered out 

of sequence 

The COP-1 protocol has also an expedited service. 
This service is used for exceptional spacecraft 
communications. Typically, this service is required 
for recovery in absence of telemetry downlink (i.e 
no CLCW), or during unexpected situations 
requiring unimpaired access to the spacecraft data 
management system. 

Figure 3.1 gives a simplified overview of the 
EURECA COP-1 Protocol. 
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Figure 3.1 EURECA COP-1 Protocol 


4. IMPLEMENTATION OF THE COP-1 
PROTOCOL 

The EURECA Commanding system only uses a 
small subset of the COP-1 services and the com- 
manding system was designed before the COP-1 
standard was available. In the event, it proved 
impossible to develop this general infrastructure 
equipment containing the EURECA standard and 
the COP-1 in the required time scale. It was there- 
fore decided to use a Mark n Telecommand 
decoder (supporting the old ESA standard) and 
implement all the necessary packet block building 
and protocol execution in software within the 
spacecraft control system at the Control Centre. 

Figure 4.1 gives an overview of the EDCS 
implementation of the COP-1 Protocol when 
commanding via an ESA Ground Station. 

The basic principle is that all the additional packet 
block building and protocol execution associated 
with the Packet Telecommand Standard are 
performed within the spacecraft control system at 
the OCC. The ground network and station 
equipment is only used to transport these data 
structures from the control centre to the spacecraft. 

4.1 COP-1 VIA NASCOM 

For Eureca the possibilities exist to transmit 
telecommands via NASA facilities 
(NASCOM/MCC) and via ESA ground stations. 
The first is only needed during the launch and early 
orbit phase and retrieval. The latter is in addition 
needed for the routine phase. The commanding via 
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COP-1 IMPLEMENTATION 



Figure 4. 1 EURECA Implementation of the COP-1 
Protocol 


NASA facilities is complex, for two reasons: first 
the different NASA ground system for 
commanding. Secondly, the users required a 
command interface that looked the same as that for 
commanding via ESA stations (except possibly for 
response times); they require for example a similar 
manual command interface and automatic com- 
manding; where real-time telemetry is available 
on-line they also require common verification. 

Figure 4.2 gives an overview of the EDCS 
implementation of the COP-1 protocol when 
commanding via NASA. 


COP-1 IMPLEMENTATION (VIA NASA) 



Figure 4.2 EURECA implementation of COP-1 via 
NASA 


The same basic principles apply m txKrnnanding via 

m ESA ground station. The NASA Infrastructure 
is only used to transport EURECA data structures 
from the control centre to the spacecraft. 

4.2 CONSIDERATIONS FOR THE 
IMPLEMENTATION OF THE COP-4 

PROTOCOL 

The COP-1 protocol is only designed to provide the 
services between two COP-1 protocol machines one 
on-ground and one on-board. In terms of network 
layers the COP-1 protocol can by classified as a 
transport layer. The COP-1 does not provide an 
end-to-end transport service. It is the responsibility 
of the implementer to develop any required Higher 
Layer protocols using the underlying services of 
the COP-1 protocol. Additional protocols may also 
required when multiple sources on the ground are 
accessing the same COP-1 machine. 

The COP-1 Sequence-Controlled Service is 
normally initiated by means of Service Directives. 
However in case of ground failures it may be 
necessary to include additional higher layer 
protocol elements to initiate the COP-1 services 
proper. This is also required to resynchronise 
between multiple ground users and on-board users. 
To allow EURECA to operate autonomously, 
EURECA executes commands from its on-board 
Master Schedule. To support the uplink of the 
Master Schedule EURECA has implemented a 
command insert counter which is reported in the 
Housekeeping Telemetry. This counter is used in 
operational procedures to restart the uplink of the 
Master Schedule in case of any ground failure. 

4.3 OPERATIONAL EXPERIENCE WITH 
COP-1 

There have been a number of occasion where the 
COP-1 protocol has successfully recovered an 
error. These cases all concerns link degradation, 
and involved the following circumstances: 

1. During die Deployment phase with a bad 
RF link between the Shuttle and EURECA 

2. During the Deployment phase where the 
EDCS did not receive a Command 
Acceptance Pattern (CAP) from NASA. 

3. During ESA ground station passes where 
the spacecraft was configured with the 
wrong antennae. 

4. During ESA ground passes where 
commanding was executed down to 0° 
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elevation (resulting in degradation of the 
telecommand and telemetry links). 

5. During on-board antenna switch over. 

6. When the OBC failed to allocate a 
Telecommand buffer (due to an OBC 
overload condition). 

Although not all of the above cases wore foreseen 
in the design of the COP-1 protocol (in particular 
case 2 and 6) the COP-1 protocol has always 
successfully recovered the error with a maximum 
of two retries. It is also important that during 
EURECA routine operations with a normal link 
budget the COP-1 protocol has never been in retry 
(i.e no transmission errors). 

5. LOW CONTACT RATIO 

5.1 MAIN DRIVER REQUIREMENTS ON 

COMMANDING SYSTEM 

The majority of EURECA’s operations are 
executed outside contact periods. Thus a command 
uplinked at time T may be time-tagged for 
execution at T +10 Hours and so will be held on 
the on-board master schedule. The relevant 
necessary telemetry to verify the execution of this 
command might not be downlinked until T + 18 
Hours, and subsequently processed to yield the 
final verification result at T + 19 Hours. This is 
illustrated schematic in figure 5.1. 


Avai lab fifty of Spacecraft Telemetry 

Spacecraft time 



Ground time 


Figure 5. 1 Relation between spacecraft generated 
data and the arrival at the OCC. 

Figure 5. 1 shows an example of five passes starting 
with a short pass followed by three long passes and 
ending with a short pass. During this pass sequence 
the on-board mass memory unit is dumped twice 


(pass 2 and pass 4). The first pass 2 dump 

telemetry is started to be routed to the OCC shortly 
alter the end of pass 2 and terminates before pass 
3. The routing of pass 4 dump telemetry is as 
shown delayed until after the last pass 5. 

This delay result in three significant requirements 
on the ground system. 

1. The Master Schedule’s acceptance of time- 
tagged commands and their subsequent 
release to end users must be emulated. 
This on-ground maintained image of the 
on-board commanding provides the 
operations staff an indirect presentation of 
the on-board commanding activities and 
the status of verification. 

2. Before each pass the commanding system 
shall prepare, an ’expected status of the 
spacecraft’ using a defined subset of 
housekeeping parameters. This is prepared 
under the assumption that ail commands 
not known to have failed have succeeded. 
As the telemetry parameters are received 
they are compared with the expected 
values, alarms being raised when 
differences are detected. This ’quick look’ 
approach may detect command failures 
hours before traditional verification can 
take place and permit corrective actions to 
be taken within the same pass. 

3. The commanding system must be able to 
verify commands using Real-Time 
Telemetry and Playback Telemetry. For 
EURECA playback telemetry will never 
arrive interleaved with real-time telemetry. 
However playback must arrive in 
chronological order, but the time of 
arrival is not significant. 

5.2 COMMAND VERIFICATION 

The basic mechanism for command verification is 
that all commands to be verified will have a 
verification window. The start of this window is 
the earliest time that the telemetry could be affected 
by the execution of the command and the end of 
the window is the time at which, if the command 
executes successfully, the telemetry must have been 
affected. If die verification criteria are met in the 
telemetry during the time window then the 
command is passed successfully; if the conditions 
have not been met at the end of the window then 
the next telemetry received decides pass or fail of 
the command. 
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For EURECA the Command Verification is a four 

stage process consisting of: 

1. Uplink verification using the Command 
Link Control Word (CLCW). This cannot 
be applied for commands executed from 
the master schedule. 

2. Verification of delivery at on-board 

destination using the end user generated 
Acknowledgement packets. 

3. Execution Verification using special 

EURECA Report Packets. 

4. Execution Verification using the 

Housekeeping Packets. 

Figure 5.2 illustrates the EURECA verification 

concept. 


Verification 



Figure 5.2 Verification 


Command verification is therefore described by a 
vector, rather than a simple success/fail indication. 
Thus an example; could be 'uplink successful', 
acknowledged in real time’, report packet 
received’, ’housekeeping confirmation not yet 
available’. Some 26 such combinations are 
possible. Command verification also involves 
processing of various special packets associated 
with commanding, namely Acknowledge, Report 
and Exception packets, as well as traditional 
verification based upon changes in telemetry 
parameters. These may be found in real-time 
Telemetry and/or Playback Telemetry, which 
arrives at the OCC at different times. 


6. LESSONS LEARNED 

The following lessons have been learned about 

packet telemetry and telecommand systems from 

development of the Eureca spacecraft control 

system and operations: 

6.1 COP-1 PROTOCOL 

1 . The COP-1 protocol has proven to be very 
reliable and is able to recover transmission 
error with minimal operational impact. 

2. It is possible to implement the COP-1 
protocol at the Control Centre using 
existing infrastructure such as the ESA 
MARK II Telecommand Controller and 
the NASCOM Remote Command 
Facilities 

3. The design of the Control Centre must 
consider end-to-end protocols and provide 
elements that make it possible to recover 
in case of ground failures. The design 
must also consider the infrastructure to be 
used. 

4. Introduction of Packet Telemetry and 
Telecommand is a major step towards 
standardisation of on-board and ground 
systems. To fully archive this goal it will 
be necessary to define standards governing 
end-to-end protocols such as File Transfer 
Protocol that are required to maintain on- 
board Master Schedules, and to support 
on-board software maintenance. 

5. The distribution of protocol handling 
between the Ground Station and the 
Control Centre has to be considered taking 
into account the mission requirements. In 
the EURECA case where commanding is 
via ESA ground stations and via NASA it 
is desirable to implement the protocol at 
the control centre. This implementation 
also allows the COP-1 to recover in case 
of ground link errors. In other cases it 
might be considered to close the COP-1 
protocol at the Ground Station. This might 
be attractive if commanding is considered 
time critical because all time critical 
functions are concentrated in the front-end 
Ground Stations. This is particularly true 
for the closed-loop operations of the COP- 
1 protocol. 
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6 . 


REFERENCES 


It Is not recommended to make the uplink 
protocol transparent to the operational 
staff. They require full visibility of the 
status of the uplink process including the 
status of the retry process. This Is 
important because considerable uplink 
delay may be introduced when COP-1 
protocol performs retries. 

6.2 LOW CONTACT RATIO 

1. The expected status is proven to be very 
useful. It gives the operational staff a 
prewarning and often triggers an 
emergency dump of on-board stored 
telemetry necessary for further 
investigation of the problem. 

2. The EURECA verification implementation 
is based on one verification window per 
command. However this window can be 
closed by the arrival of any Telemetry 
Packet. This has caused problems because 
some on-board users have problems 
maintaining time synchronisation with the 
OBC and their local clock have therefore 
drifted into the future. The arrival of a 
packet with future time causes verification 
windows for other commands be falsely 
closed. It should therefore be considered 
to make the closing of the command 
verification window telemetry packet 
specific. 

7. CONCLUSION 

At the time of writing (October 1992) EURECA 
has been successfully supported by the Control 
Centre for 3 months. During this time the EDCS 
has successfully received and processed over 10 
million telemetry packets and over 60000 
commands has been sent. The COP-1 protocol has 
proven to be very reliable and given the operational 
staff much confidence in die EURECA 
commanding system. 

The low contact ratio for EURECA has proven not 
to be a major problem. The functions provided by 
the EDCS gives the operational staff sufficient 
information for quick assessment of the status of 
the spacecraft during the short passes. 
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